Apparatus, method, and program for designing real-time system

ABSTRACT

A real-time system designing apparatus helps easily forming a real-time system and shortening the development period of applications to be designed based on the real-time system.  
     The apparatus has a user inter face for receiving data entered by a user and displaying extracted parameters, etc., for the user, a parameter extractor for extracting parameters representing the start and end states of each sub-scenario, a state memory for storing the extracted parameters, a connector-tester for connecting sub-scenarios together and testing the consistency of the connected sub-scenarios, and a connection memory for storing sub-scenario connection data.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based upon and claims the benefit of priorityfrom the prior Japanese Patent Application No. 2000-241688, filed onAug. 9, 2000; the entire contents of which are incorporated herein byreference.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] The present invention relates to an apparatus for designing areal-time system, a method of designing a real-time system, and aprogram for making a computer execute the real-time system designingmethod. In particular, the present invention relates to a technique ofdesigning a real-time system by controlling the behavioral consistencyof the system and by describing parallel operations of the system intime series.

[0004] 2. Description of the Related Art

[0005] When forming a real-time system for concurrently processing aplurality of tasks, it is difficult to realize system behavioralconsistency and synchronous task-to-task communication becausespontaneous interrupts and periodic time-out processes asynchronouslybother the tasks. As the scale of a real-time system to designincreases, it becomes more difficult to include such interrupts andtime-out processes in the designing of the system.

[0006] To simplify the designing of a real-time system, there aretechniques of describing task operations in time series.

[0007] The behavior of each task is affected by asynchronous factorssuch as interrupts as mentioned above, and therefore, it is difficultfor general real-time systems to define a total system behavior from asingle time series of data.

[0008] Forming a real-time system and developing applications based onthe real-time system, therefore, needs a long time.

BRIEF SUMMARY OF THE INVENTION

[0009] An apparatus for designing a real-time system involving aplurality of tasks according to an embodiment of the present inventioncomprises an asynchronous factor tester for testing whether or not taskoperations arranged in time series in a given section are affected byasynchronously occurring factors.

[0010] The “task operations arranged in time series in a given section”are a series of task operations such as 1) a task A updating a task Bfrom dormant state to ready state, 2) the task A updating a task C fromdormant state to ready state, and 3) the task A updating the task Aitself from ready state to dormant state.

[0011] The “asynchronous factors” include interrupt and time-outprocesses. If an interrupt, which is an asynchronous factor, causes nobranching, it is determined that the interrupt has no influence on taskoperations.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0012]FIG. 1 shows an example of a scenario to define the behavior of areal-time system;

[0013]FIG. 2 shows a plurality of scenarios combined to define thebehavior of a real-time system;

[0014]FIG. 3 shows an example of a sub-scenario having parameters todetermine the sub-scenario's connectivity;

[0015]FIG. 4 is a functional block diagram generally showing anapparatus for designing a real-time system according to an embodiment ofthe present invention;

[0016]FIG. 5 is a flowchart showing the operation of a parameterextractor 12 contained in the apparatus of FIG. 4;

[0017]FIG. 6 is a flowchart showing “(b) Initial state determination” ofFIG. 5;

[0018]FIG. 7 is a flowchart showing “(c) Operation registration” of FIG.5;

[0019]FIG. 8 is a flowchart showing “(d) Data extraction” of FIG. 5;

[0020]FIG. 9 is a flowchart showing “(e) State extraction” of FIG. 5;

[0021]FIG. 10 is a flowchart showing “(f) Consistency test” of FIG. 5;

[0022]FIG. 11 is a flowchart showing the operation of a connector-tester13 contained in the apparatus of FIG. 4;

[0023]FIG. 12 shows a sub-scenario 1 to define a task S activating tasksA and B;

[0024]FIG. 13 shows a sub-scenario 2 to define the task B determiningwhether an evaluation result is valid or invalid;

[0025]FIG. 14 shows a sub-scenario 3 to define the task B accessing anOS resource;

[0026]FIG. 15 shows a sub-scenario 4 to define the task A operatingasynchronously;

[0027]FIG. 16 shows a sub-scenario 5 to define a resource or dataasynchronously accessed by the task A;

[0028]FIG. 17 roughly shows a real-time system constructed by connectingthe sub-scenarios 1 to 5; and

[0029]FIG. 18 shows an example of a computer system used to execute thereal-time system designing method of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0030] Embodiments of the present invention will be described withreference to the accompanying drawings. It is to be noted that the sameor similar reference numerals are applied to the same or similar partsand elements throughout the drawings, and the description of the same orsimilar parts and elements will be omitted or simplified.

[0031] In the following explanation, a user designs a real-time systembased on a real-time OS. The present invention expresses the time-seriesbehavior of a real-time system with “scenarios.” The present inventionprepares sub-scenarios each representing a limited section of areal-time system and connects the sub-scenarios without inconsistency,to define the behavior of the real-time system. In this embodiment, thereal-time OS is μITRON 3.0, or any other real-time OS whosespecifications are similar to those of μITRON 3.0. The definitions oftechnical terms to describe a real-time system in the followingexplanation are based on the specifications of μITRON 3.0.

[0032]FIG. 1 shows an example of a scenario defining the behavior of areal-time system according to an embodiment of the present invention.The scenario defines the behavior of the real-time system in timeseries.

[0033] The scenario shows, in time series, the possible states andinteractions of tasks involved in the real-time system.

[0034] Generally, the operating conditions of a real-time system arechanged by, for example, interrupts, and therefore, it is impossible todefine the total behavior of the real-time system with a singlescenario. For example, an interrupt occurring at T1 may transfer controlto a task A instead of a task B. This type of behavior is unable todefine with a single scenario.

[0035] To cope with this problem, the present invention enables a systemdeveloper or a user to define short scenarios that describe the behaviorof tasks at various locations in a real-time system. The short scenariosare connected to one another as shown in FIG. 2, to define the totalbehavior of the real-time system. The short scenarios are called“sub-scenarios” in this specification.

[0036] Each sub-scenario corresponds to a section in a general scenariodescribing a real-time system. In each sub-scenario, each task operationis free from the influence of external factors. Within a sub-scenario,no branching occurs even if an asynchronous event such as an interruptoccurs.

[0037] Each sub-scenario is extendable as long as the scenario definingrules mentioned above are kept. A sub-scenario may be divided into twoif the definition of a real-time system to design allows it, so that thelatter half of the divided sub-scenarios may be used as a loop startingpoint.

[0038]FIG. 3 shows an example of a sub-scenario having parameters todetermine the connectivity of the sub-scenario.

[0039] In FIG. 3, the sub-scenario is defined with (1) start task statessuch as ready and wait states, (2) end task states, and (3) real-time OSresources such as flags and semaphores or global variables to beaccessed in the sub-scenario. The embodiment of the present inventionincludes a mechanism of extracting sub-scenario parameters correspondingto task states from every sub-scenario.

[0040] The embodiment of the present invention also includes a mechanismof combining sub-scenarios into a real-time system by collating the endstate parameters of a given sub-scenario with the start state parametersof a sub-scenario to be connected to the given sub-scenario, to test ifthe real-time system operates consistently.

[0041] Due to these mechanisms, each sub-scenario according to theembodiment of the present invention is free from the influence ofasynchronous factors that may change real-time OS resources and globalvariables. The sub-scenarios are used in combination to define branchingprocesses to handle changes in the real-time OS resources and globalvariables, thereby securing the consistency of a real-time system to bedesigned.

[0042]FIG. 4 is a functional block diagram generally showing anapparatus for designing a real-time system according to an embodiment ofthe present invention. The apparatus at least includes a user interface11, a parameter extractor 12, a connector-tester 13, a state memory 14,and a connection memory 15.

[0043] The user interface 11 receives data entered by a user. Theentered data relates to tasks, real-time OS resources, global variables,and task operations defined in sub-scenarios. The task operationsinclude, for example, issuing system calls and reading/writing theglobal variables. The user interface 11 also has a function ofdisplaying user-defined sub-scenario parameters, task operations,sub-scenario state changes in time series as shown in FIG. 3.

[0044] The parameter extractor 12 receives sub-scenario start stateparameters and task operation data from the user interface 11 andexecutes two functions. The two functions are (1) determining whether ornot a sub-scenario with entered operations terminates and (2) extractingparameters from a defined sub-scenario. Results of the parameterextractor 12 are supplied to the user interface 11, which provides theresults to the user. The parameters extracted by the parameter extractor12 are written into the state memory 14.

[0045] The connector-tester 13 receives connection data for twosub-scenarios selected by the user from among sub-scenarios entered intothe user interface 11. The connector-tester 13 executes two functions.One is carrying out a consistency test to see if the two sub-scenarioscause no system inconsistency when they are connected to each other. Theother is testing a loop. When the end of a sub-scenario is connected tothe start of a first one of the selected two sub-scenarios that containsasynchronous factors, to form a loop, the connector-tester 13 readsparameters of all sub-scenarios concerned from the state memory 14 andtests system operation consistency according to the read data. When aninterrupt or time-out process is defined, the connector-tester 13 alsocarries out the two functions. A consistency test result from theconnector-tester 13 is supplied to the user interface 11. Connectiondata for the two sub-scenarios is stored in the connection memory 15.

[0046] The state memory 14 has a function of storing start and end stateparameters extracted by the parameter extractor 12 from sub-scenariosdefined by the user.

[0047] The connection memory 15 has a function of storing the connectiondata of sub-scenarios provided by the connector-tester 13 and datarelated to sub-scenarios that involve asynchronous factors.

[0048] Forming an application based on a real-time OS and describing areal-time system involving the application with sub-scenarios accordingto an embodiment of the present invention will be explained. In thefollowing explanation, the real-time OS is assumed to be the μITRON 3.0.

[0049] An outline of the application to be formed is as follows:

[0050] 1) The application carries out a dialing operation for atelephone set.

[0051] 2) The application receives data entered by a user with numerickeys and sends a dial pulse signal representing the received data to atelephone line.

[0052] The specifications of the application are as follows:

[0053] 1) The telephone set has other keys in addition to the numerickeys. If a key other than the numeric keys is pressed during a dialingoperation, the pressed key is ignored to take no action.

[0054] 2) The dialing operation is carried out by software using pulsestrings.

[0055] 3) During the dialing operation, new keyed data is acceptable.

[0056] The structure of the real-time system is as follows:

[0057] Tasks involved in the real-time system are a task S of the firstpriority for a startup process, a task A of the second priority fordialing, and a task B of the third priority for receiving keyed data.

[0058] The real-time system involves only one OS resource, i.e., amessage buffer (mbf).

[0059] Data used in the real-time system is numeric keyed data.

[0060] System calls based on μITRON 3.0 used by the embodiment include“sta_tsk,” “ext_tsk,” “snd_mbf,” “rcv_mbf,” and “dly_tsk.”

[0061] A system restriction employed by the embodiment is that onepriority level involves only one task.

[0062] [Sub-scenario Definition]

[0063] <Setting Parameters Common to All Sub-scenarios>

[0064] The user first enters tasks to be included in the real-timesystem, the priority levels of the tasks, and resources into the userinterface 11 of FIG. 4. The user specifies tasks that are ready at thestart of the real-time system.

[0065] According to the embodiment, the user enters 1) the tasks S, A,and B, 2) the priority levels of the tasks S, A, and B, 3) a messagebuffer (mbf) as a resource, and 4) the task S as a task that is ready atthe start of the real-time system. These data pieces are transferredfrom the user interface 11 to the parameter extractor 12.

[0066]FIG. 5 is a flowchart showing the operation of the parameterextractor 12 of FIG. 4, FIG. 6 is a flowchart showing “(b) Initial statedetermination” of FIG. 5, FIG. 7 is a flowchart showing “(c) Operationregistration” of FIG. 5, FIG. 8 is a flowchart showing “(d) Dataextraction” of FIG. 5, FIG. 9 is a flowchart showing “(e) Stateextraction” of FIG. 5, FIG. 10 is a flowchart showing “(f) Consistencytest” of FIG. 5, FIG. 11 is a flowchart showing the operation of theconnector-tester 13 of FIG. 4, FIGS. 12 to 16 show sub-scenarios 1 to 5,and FIG. 17 shows a concept of sub-scenario connection.

[0067] Defining the sub-scenario 1 of FIG. 12 will be explained. Thesub-scenario 1 describes the task S activating the tasks A and B.

[0068] In step S20 “(a) Initial setting” of FIG. 5, the user interface11 receives data entered by the user.

[0069] In step S30 “(b) Initial state determination” of FIG. 5, theparameter extractor 12 receives data from the user interface 11 andextracts start state parameters from the received data. The extractedparameters indicate that the task S is ready, the tasks A and B aredormant, and a resource to access is a message buffer (mbf). Theextracted data is sent to the user interface 11, and at the same time,is stored in the state memory 14.

[0070] Step S40 “(c) Operation registration” of FIG. 5 asks the userinterface 11 for the next operation of the task S. The user interface 11shows the user all task states and waits for the user registering anoperation of the task S. To define the sub-scenario 1, the userregisters the issuance of the system call “sta_tsk” for the task A, thesystem call “sta_tsk” for the task B, and the system call “ext_tsk.” Thedetails of registration of these system calls will be explained.

[0071] <Registering “sta_tsk(Task A)” Issuance in Task S>

[0072] Referring to “(c) Operation registration” of FIG. 7, step S41checks to see if there is at least one ready task. The task S is ready,and therefore, step S41 is YES.

[0073] Step S42 finds the task S as a task having the highest priorityamong tasks that are ready.

[0074] Step S43 asks the user interface 11 for task operation definingdata. The user enters “sta_tsk(task A)” as an operation for the task Sinto the user interface 11.

[0075] The flow advances to “(d) Data extraction” of FIG. 8.

[0076] The registered task operation “sta_tsk” accesses no resource ordata, and therefore, step S51 is NO.

[0077] The flow advances to “(e) State extraction” of FIG. 9.

[0078] The registered task operation “sta_tsk” is not “wai_sem,” etc.,and therefore, step S610 is NO.

[0079] The registered task operation is “sta_tsk,” and therefore, stepS620 is YES.

[0080] There is no task having higher priority than the task S, andtherefore, step S621 is NO. Step S640 asks the user interface 11 whetheror not the sub-scenario definition must be finished.

[0081] The sub-scenario definition is not finished, and therefore, stepS641 is NO.

[0082] The flow returns to “(c) Operation registration” of FIG. 7.

[0083] <Registering “sta_tsk(Task B)” Issuance in Task S>

[0084] Step S41 of FIG. 7 checks to see if there is at least one readytask. The tasks S and A are ready at this moment, and therefore, stepS41 is YES.

[0085] Step S42 detects the task S as a task having the highest priorityamong the ready tasks.

[0086] Step S43 asks the user interface 11 for task operation definingdata for the task S. The user enters “sta_tsk(task B)” as an operationfor the task S into the user interface 11.

[0087] The flow advances to “(d) Data extraction” of FIG. 8.

[0088] The registered task operation “sta_tsk” accesses no resource ordata, and therefore, step S51 is NO.

[0089] The flow advances to “(e) State extraction” of FIG. 9.

[0090] The registered task operation “sta_tsk” is not “wai_sem,” etc.,and therefore, step S610 is NO.

[0091] The registered task operation is “sta_tsk,” and therefore, stepS620 is YES.

[0092] There is no task having higher priority than the task S, andtherefore, step S621 is NO. Step S640 asks the user interface 11 whetheror not the sub-scenario definition must be finished.

[0093] The sub-scenario definition is not finished, and therefore, stepS641 is NO.

[0094] The flow returns to “(c) Operation registration” of FIG. 7.

[0095] <Registering “ext_tsk” Issuance in Task S>

[0096] Step S41 of FIG. 7 checks to see if there is at least one readytask. The tasks S, A, and B are ready at this moment, and therefore,step S41 is YES.

[0097] Step S42 detects the task S as a task having the highest priorityamong the ready tasks.

[0098] Step S43 asks the user interface 11 for task operation definingdata. The user enters “ext_tsk” as an operation for the task S into theuser interface 11.

[0099] The flow advances to “(d) Data extraction” of FIG. 8.

[0100] The registered task operation “ext_tsk” accesses no resource ordata, and therefore, step S51 is NO.

[0101] The flow advances to “(e) State extraction” of FIG. 9.

[0102] Due to the registered task operation “ext_tsk,” step S610 is YES.

[0103] Due to the registered task operation “ext_tsk,” step S611 makesthe task S dormant.

[0104] The tasks A and B are ready. Namely, there is a ready task havinglower priority than the task S, and therefore, step S612 is YES. StepS640 asks the user interface 11 whether or not the sub-scenariodefinition must be finished.

[0105] The sub-scenario definition is not finished, and therefore, stepS641 is NO.

[0106] The flow returns to “(c) Operation registration” of FIG. 7.

[0107] <Registering “rcv_mbf” Issuance in Task A>

[0108] Step S41 of FIG. 7 checks to see if there is at least one readytask. The tasks A and B are ready at this moment, and therefore, stepS41 is YES.

[0109] Step S42 detects the task A as a task having the highest priorityamong the ready tasks.

[0110] Step S43 asks the user interface 11 for task operation definingdata. The user enters “rcv_mbf” as an operation for the task A into theuser interface 11.

[0111] The flow advances to “(d) Data extraction” of FIG. 8.

[0112] The registered task “rcv_mbf” accesses resources or data, andtherefore, step S51 is YES.

[0113] Step S52 extracts the message buffer (mbf) as a resource toaccess.

[0114] The present scenario, i.e., the sub-scenario 1 has not issued“dly_tsk,” and therefore, step S53 is NO.

[0115] An access result causes no branching of the scenario, andtherefore, step S55 is NO.

[0116] The sub-scenario definition is not finished, and therefore, stepS58 is NO.

[0117] The flow advances to “(e) State extraction” of FIG. 9.

[0118] Due to the registered task operation “rcv_mbf,” step S610 of FIG.9 is YES.

[0119] Due to the registered task operation “rcv_mbf,” step S611 putsthe task A in wait state to wait for data from the message buffer.

[0120] The task B having lower priority than the task A is ready, andtherefore, step S612 is YES. Step S640 asks the user interface 11whether or not the sub-scenario definition must be finished.

[0121] The sub-scenario definition is finished, and therefore, step S641is YES.

[0122] The flow advances to “(f) Consistency test” of FIG. 10.

[0123] End state parameters are not extracted, and therefore, step S71of FIG. 10 is NO.

[0124] Step S73 asks the user interface 11 whether or not a resource towait must be added to the tasks.

[0125] No wait resource is added to the tasks, and therefore, step S75is NO.

[0126] Step S77 defines, as end state parameters of the sub-scenario 1,the extracted parameters including “dormant” for the task S, “wait(mbf)”for the task A, “ready” for the task B, and the message buffer servingas a resource to be accessed.

[0127] This completes the definition of the sub-scenario 1 of FIG. 12.

[0128] When a sub-scenario is partly amended or a new sub-scenario isinserted, there are already defined front and rear sub-scenarios to beconnected to the amended or inserted sub-scenario. Namely, the start andend states of the amended or inserted sub-scenario are already defined.When step S71 of FIG. 10 is YES, it means that a rear scenario connectedto the sub-scenario 1 is already defined.

[0129] <User Defining Process of Evaluating Keyed Data in Task B>

[0130] Defining a sub-scenario 2 of FIG. 13 will be explained. Thesub-scenario 2 describes the task B 1) accepting keyed data from atelephone user and 2) evaluating if the keyed data is valid. Thesub-scenario 2 involves conditional branching, and therefore, has twoend states. In this regard, the sub-scenario 2 greatly differs from thesub-scenario 1.

[0131] The parameter extractor 12 of FIG. 4 carries out “(b) Initialstate determination” of FIGS. 5 and 6.

[0132] The present scenario, i.e., the sub-scenario 2 is not at thestart of the system, and therefore, step S32 of FIG. 6 is NO.

[0133] The sub-scenario 2 is irrelevant to a delay wakeup task, andtherefore, step S33 is NO. The “delay wakeup task” is a ready state taskwhich woke up from a wait state due to a time-out after an issuance ofsystem call “dly_tsk”.

[0134] Step S34 extracts the end state of the front sub-scenario, i.e.,the sub-scenario 1 as the start state of the sub-scenario 2 and outputsthe start state to the user interface 11.

[0135] The end state of the sub-scenario 1 is not branching, andtherefore, step S35 is NO.

[0136] There is no available resource for the resource waiting task,i.e., the task A at the start of the sub-scenario 2, and therefore, stepS36 is NO.

[0137] A rear scenario, i.e., a sub-scenario 3 is not defined yet atthis moment, and therefore, step S37 is NO.

[0138] The flow advances to “(c) Operation registration” of FIG. 7.

[0139] There is a ready task, i.e., the task B, and therefore, step S41of FIG. 7 is YES.

[0140] Step S42 finds the task B as a task having the highest priorityamong tasks that are ready.

[0141] Step S43 asks the user interface 11 for operation defining dataof the task B.

[0142] The flow advances to “(d) Data extraction” of FIG. 8.

[0143] The registered task operation “keyed data” accesses no resourceor data, and therefore, step S51 is NO.

[0144] The flow advances to “(e) State extraction” of FIG. 9.

[0145] The registered task operation is not “wai_sem,” etc., andtherefore, step S610 is NO.

[0146] The registered task operation is not “sig_sem,” etc., andtherefore, step S620 is NO.

[0147] The registered task operation is not “dly_sk,” and therefore,step S630 is NO.

[0148] Step S640 asks the user interface 11 whether or not thesub-scenario definition must be finished.

[0149] The sub-scenario definition is not finished, and therefore, stepS641 is NO.

[0150] The flow returns to “(c) Operation registration” of FIG. 7.

[0151] The task B is ready. Namely, there is at least one ready task,and therefore, step S41 of FIG. 7 is YES.

[0152] Step S42 detects the task B as a task having the highest priorityamong the ready tasks.

[0153] Step S43 asks the user interface 11 for task operation definingdata of the task B.

[0154] The flow advances to “(d) Data extraction” of FIG. 8.

[0155] The registered task operation “evaluation” accesses resources ordata, and therefore, step S51 is YES. Step S52 extracts a resource ordata to access.

[0156] The present scenario, i.e., the sub-scenario 2 is not a delaywakeup task, and therefore, step S53 is NO.

[0157] The sub-scenario 2 is branched according to an access result, andtherefore, step S55 is YES. Step S56 asks the user interface 11 for thenumber of branches. Step S57 extracts the number of branches andparameters to determine branch targets. According the embodiment, theuser enters that there are two branches, i.e., a keyed data valid branchand a keyed data invalid branch and that an evaluation parameter is anevaluation result.

[0158] The flow advances to “(f) Consistency test” of FIG. 10.

[0159] End state parameters are not extracted, and therefore, step S71of FIG. 10 is NO.

[0160] Step S73 asks the user interface 11 whether or not a resource towait must be added to the tasks.

[0161] If a wait resource is added to the tasks, step S75 is YES. Inthis case, step S76 confirms that the resource to be added is notaccessed in the sub-scenario 2 and adds the wait resource.

[0162] The task A has no defined operation, and therefore, a wait objectmay be added to the “wait(mbf)” state of the task A. Accordingly, theuser adds wait state based on “dly_tsk” as a start state parameter andend state parameter to the task A.

[0163] This completes the definition of the sub-scenario 2 of FIG. 13.

[0164] <User Defining Process of Accessing OS Resource in Task B>

[0165] Defining a sub-scenario 3 of FIG. 14 will be explained. Thesub-scenario 3 describes the task B accessing an OS resource to transmitan evaluation result.

[0166] If the keyed data evaluation carried out by the frontsub-scenario 2 is “valid,” the task B issues “snd_mbf” to transmit thekeyed data to the task A that is waiting for receiving data from themessage buffer.

[0167] If the keyed data evaluation carried out by the sub-scenario 2 is“invalid,” the task B carries out a loop operation until valid keyeddata is received. Due to this, the end of the sub-scenario 2 is coupledto the start of the sub-scenario 2. This coupling will be explainedlater.

[0168] When defining the sub-scenario 3, “(b) Initial statedetermination” of FIG. 6 carried out by the parameter extractor 12determines that the end state of the front scenario 2 involvesbranching. Namely, step S35 of FIG. 6 is YES. Step S38 extracts abranching evaluation factor “evaluation result” and a branching content“valid” and employs them as start state parameters in addition to othertask states.

[0169] Like the definition of the sub-scenario 1, the user enters anoperation of the task B of issuing “snd_mbf.” The registered taskoperation accesses a resource or data, and therefore, step S51 of “(d)Data extraction” of FIG. 8 is YES.

[0170] The present scenario, i.e., the sub-scenario 3 has not issued“dly_tsk,” and therefore, step S53 is NO.

[0171] The sub-scenario 3 involves no branching according to a result ofaccessing the message buffer, and therefore, step S55 is NO.

[0172] The operation of the task A after receiving data from the messagebuffer is used to start a loop, and therefore, the user selects YES instep S58 to finish the sub-scenario definition. If the sub-scenariodefinition is not finished and if an operation for the task A is definedcontinuously, the sub-scenario may be divided later, if required.

[0173] <User Defining Asynchronous Process (Time-out Process in thisEmbodiment) in Task A>

[0174] Defining a sub-scenario 4 of FIG. 15 will be explained. Thesub-scenario 4 describes the task A carrying out dialing and a time-outprocess to accept keyed data from the telephone user during the dialing.

[0175] “(b) Initial state determination” of FIG. 6 is carried out atfirst.

[0176] The present scenario, i.e., the sub-scenario 4 is not at thesystem start, and therefore, step S32 is NO. The sub-scenario 4 is not adelay wakeup task, and therefore, step S33 is NO.

[0177] Step S34 extracts the end state of the front sub-scenario, i.e.,the sub-scenario 3 as the start state of the sub-scenario 4. Namely, thestart state of the sub-scenario 4 includes the task S being dormant, thetask A being wait(mbf), and the task B being ready.

[0178] The end state of the sub-scenario 3 involves branching, andtherefore, step S35 is YES.

[0179] Step S38 extracts the data, resources, and the contents thereofused for evaluating branching conditions. Namely, step S38 extracts“mbf=available” and “evaluation result =valid.”

[0180] For the resource waiting task A, the resource “mbf” is ready tosend data at the start of the sub-scenario 4, and therefore, step S36 isYES.

[0181] Step S39 updates the resource waiting task A to ready state andthe resource “mbf” to a transmitted state.

[0182] A rear scenario, i.e., a sub-scenario 5 is not defined yet atthis moment, and therefore, step S37 is NO. The flow advances to “(c)Operation registration” of FIG. 7.

[0183] Like the definition of the sub-scenario 1, the user enters, forthe task A, a process of dialing based on the received message and aprocess of issuing the system call “dly_tsk” to wait for a predeterminedperiod to finish the dialing.

[0184] After “(c) Operation registration” of FIG. 7, the flow advancesto “(d) Data extraction” of FIG. 8.

[0185] The registered task operation “dly_tsk” accesses no resource ordata, and therefore, step S51 is NO. The flow advances to “(e) Stateextraction” of FIG. 9.

[0186] In FIG. 9, the registered task operation is “dly_tsk,” andtherefore, step S630 is YES. Step S631 updates the state of the task Ato “wait(dly_tsk).” The flow advances to “(f) Consistency test” of FIG.10.

[0187] <User Defining Resources or Data to be Accessed in AsynchronousProcess>

[0188] Defining a sub-scenario 5 of FIG. 16 will be explained. Thesub-scenario 5 describes the task A accessing an OS resource after thetime-out of the wait state “dly_tsk.”

[0189] The present scenario, i.e., the sub-scenario 5 is a delay wakeuptask, and therefore, step S33 of FIG. 6 is YES. Accordingly, the delaywakeup task, i.e., the task A is extracted as “ready” and the othertasks as “don't care.” These states are extracted as the start state ofthe sub-scenario 5.

[0190] The flow advances to “(c) Operation registration” of FIG. 7.

[0191] Like the definition of the sub-scenario 1, the user registers anoperation for the task A. The operation to register is that the task Aissues “rcv_mbf” to wait for dial data from the message buffer. The taskA is an asynchronous wakeup task, and therefore, the operation must bedefined so that the task A can cope with any change in the messagebuffer under any system state.

[0192] To secure this, step S54 of “(d) Data extraction” of FIG. 8extracts the message buffer and writes it as asynchronously varying datainto the state memory 14.

[0193] In “(e) State extraction” of FIG. 9, step S612 is NO to indicatethat there is no ready task of lower priority. This completes thedefinition of the sub-scenario 5, and the flow goes to “(f) Consistencytest” of FIG. 10.

[0194] Thus, the definition of the sub-scenarios 1 to 5 is complete.

[0195] [Connecting Sub-scenarios and Forming Real-Time System]

[0196]FIG. 11 is a flowchart showing the operation of connectingsub-scenarios, and FIG. 17 roughly shows a real-time system formed byconnecting the sub-scenarios 1 to 5. Connecting sub-scenarios accordingto the flow of FIG. 11 forms a real-time system that consistentlyoperates. This flow is executed by the consistency tester 13 of FIG. 4.In FIG. 17, parenthesized numbers (1) to (5) represent the sub-scenarios1 to 5. The sub-scenario 5 is asynchronous, and therefore, a dotted lineis connected thereto.

[0197] When connecting the sub-scenario 2 to the sub-scenario 1, theconsistency tester 13 1) reads all task start states (with data andresources, if any) of the rear scenario, i.e., the sub-scenario 2 andall task end states (with data and resources, if any) of the frontscenario, i.e., the sub-scenario 1, 2) compares corresponding stateparameters with one another, and 3) determines whether or not the startstate parameters of the rear scenario agree with the end stateparameters of the front scenario. This is done in step S803 of FIG. 11.In this embodiment, all parameters agree with one another, andtherefore, step S803 is YES.

[0198] Steps S804 to S807 test the definitions of the rear sub-scenario2. Namely, step S804 checks to see if a loop is formed and provides NO.Step S805 checks to see if the rear scenario involves “dly_tsk” andprovides NO. Step S806 checks to see if the rear scenario accessesasynchronously varying data and provides NO. Step S807 completes theconnection between the sub-scenarios 1 and 2 and provides the relatedconnection data.

[0199] These processes follow steps S801, S802, S803, S804, S805, S806,S807, and S808 of FIG. 11.

[0200] The sub-scenario 2 involves two end states, and therefore, theuser must select, in step S802 of FIG. 11, two sub-scenarios to beconnected to the sub-scenario 2 according to the two end states.

[0201] If the end state of the sub-scenario 2 is “evaluationresult=invalid,” the task B must be looped to wait for keyed data. Torealize this, the user connects the end of the sub-scenario 2 to thestart thereof. Comparing the start and end states of the sub-scenario 2with each other, it is understood that the end state “evaluation result”is not present at the start of the sub-scenario 2. In this case,parameters that are present at the start of the sub-scenario 2 arecompared with corresponding end state parameters of the frontsub-scenario, to establish connection. In this embodiment, only the taskstates are compared with one another to see if they agree with oneanother.

[0202] These processes follow steps S801, S802, S803, S804, S815, S807,and S808 of FIG. 11.

[0203] If the end state of the sub-scenario 2 is “evaluationresult=valid,” the sub-scenario 3 is connected to the sub-scenario 2,and the evaluation result is transferred to the message buffer.Connecting the sub-scenarios 2 and 3 is carried out like connecting thesub-scenarios 1 and 2. These processes follow steps S801, S802, S803,S804, S805, S806, S807, and S808 of FIG. 11.

[0204] Connection of the sub-scenarios 3 and 4 is similarly carried out.In the subscenario 4, the task A issues the system call “dly_tsk.”Namely, step S805 is YES to indicate that the rear scenario involves theissuance of “dly_tsk.” Step S814 extracts a “dly_tsk” issuing location.

[0205] The parameter extractor 12 of FIG. 4 has extracted the messagebuffer as asynchronous data, and the sub-scenario 4 involves a receptionprocess of data from the message buffer. Accordingly, step S806 is YESto indicate that the rear scenario accesses asynchronously varying data,and step S812 transfers this determination to the user interface 11. Itis determined that no asynchronous change occurs in the message bufferat this moment, and therefore, step S813 is YES to indicate that thesub-scenario 4 is connectable.

[0206] These processes follow steps S801, S802, S803, S804, S805, S814,S806, S812, and S813 of FIG. 11.

[0207] Connection of the sub-scenario 4 to the sub-scenario 2 will beexplained. To wait for the next keyed data after dialing, the userconnects the end of the sub-scenario 4 to the start of the sub-scenario2. This connection is achieved like the connection of the sub-scenarios1 and 2. In FIG. 11, step S804 is YES to indicate that a loop is formed.The sub-scenario 3 contained in the loop accesses asynchronously varyingdata, i.e., the message buffer, step S815 is YES to indicate that theloop contains a sub-scenario that accesses asynchronously varying data.Step S817 informs the user, through the user interface 11, that the taskA may affect the task B in the sub-scenario 3. Step S807 connects thesub-scenario 4 to the sub-scenario 2 and provides the connection data.

[0208] These processes follow steps S801, S802, S803, S804, S815, S816,S817, S807, S808, and S818 of FIG. 11.

[0209] The sub-scenario 5 starts from a wakeup due to time-out of thewait state “dly_tsk.” Accordingly, it is impossible to determine asub-scenario to be connected in front of the sub-scenario 5, andtherefore, only a rear sub-scenario is connected to the sub-scenario 5.Step S802 asks the user interface 11 for rear scenarios, selectssub-scenarios to be executed after the issuance of “dly_tsk” accordingto all read scenario parameters, and displays the selected sub-scenariosfor the user. In this embodiment, the subscenarios to be executed afterthe issuance of “dly_tsk” are the sub-scenarios 2, 3, and 4. It isdetermined that all of the sub-scenarios 2, 3, and 4 have start statesagreeing with the end state of the sub-scenario 5, and therefore, thateach of them is connectable to the end of the sub-scenario 5. Thesub-scenarios 2, 3, and 4 are presented to the user through the userinterface 11.

[0210] In this way, the connection of the sub-scenarios shown in FIG. 17is completed to finish the real-time system.

[0211] According to the present invention, each sub-scenario causes nobranching due to asynchronous interrupts. The present invention checksthe end states and start states of sub-scenarios before connecting thesub-scenarios to one another, to cause no inconsistency when thesub-scenarios are connected together to form a real-time system.

[0212] The steps of the real-time system designing method of the presentinvention may be described as a computer program and stored in a storagemedium. The program in the storage medium is read and executed by acomputer to carry out the real-time system designing steps. The storagemedium may be any medium capable of storing computer programs, such as amemory, a magnetic disk, an optical disk, and a magnetic tape.

[0213]FIG. 18 roughly shows an example of a computer system that iscapable of reading the real-time system designing program of the presentinvention from a storage medium and executing the program. The computersystem 80 has a floppy disk drive 81 and a CD-ROM drive 82. A magneticfloppy disk 83 and an optical CD-ROM 84 store programs including thereal-time system designing program of the present invention and areinserted into the drives 81 and 82, respectively. The programs in thefloppy disk 83 and CD-ROM 84 are read by and installed in the computersystem 80. A drive for handling a ROM 85 (for example, a game pack) anda magnetic cassette tape 86 may be connected to the computer system 80,the ROM 85 and cassette tape 86 being used to store programs such as thereal-time system designing program of the present invention.

[0214] In summary, the present invention is capable of designing areal-time system capable of consistently executing a plurality ofoperations in parallel and controlling synchronous communication amongthe operations. The present invention is also capable of shortening thedevelopment period of applications to be designed based on the real-timesystem.

[0215] Various modifications will become possible for those skilled inthe art after receiving the teachings of the present disclosure withoutdeparting from the scope thereof.

What is claimed is:
 1. An apparatus for designing a real-time systeminvolving a plurality of tasks, the apparatus comprising: anasynchronous factor tester testing whether or not task operationsarranged in time series in each section of the real-time system areaffected by asynchronously occurring factors.
 2. The apparatus of claim1, wherein the asynchronous factor tester comprises: a parameterextractor extracting the asynchronously occurring factor of each sectionof the real-time system; and a branch tester testing whether or not theasynchronously occurring factor occurs branching of the each section. 3.The apparatus of claim 1, wherein the asynchronously occurring factorincludes interrupt and time-out process.
 4. An apparatus for designing areal-time system involving a plurality of tasks, the apparatuscomprising: a connector connecting sections each containing a series oftasks that are not affected by asynchronously occurring factors, to oneanother to form the real-time system; and a tester testing if theconnected sections operate consistently.
 5. The apparatus of claim 4,wherein the tester comprises: a reader reading a task start state of therear section of the real-time system and a task end state of the frontsection of the real-time system; a comparator comparing the task startstate of the rear section with corresponding the task end state of thefront section; and a determination device determining whether or not thetask start state of the rear section agree with the task end state ofthe front section.
 6. The apparatus of claim 5, wherein the task stateincludes Dormant, Wait, Ready and Run.
 7. A method for designing areal-time system involving a plurality of tasks, the method comprising:testing whether or not task operations arranged in time series in eachsection of the real-time system are affected by asynchronously occurringfactors.
 8. The method of claim 7, wherein the testing operationcomprises: extracting the asynchronously occurring factor of eachsection of the real-time system, and testing whether or not theasynchronously occurring factor occurs branching of the each section. 9.The method of claim 7, wherein the asynchronously occurring factorincludes interrupt and time-out process.
 10. A method for designing areal-time system involving a plurality of tasks, the method comprising:connecting sections each containing a series of tasks that are notaffected by asynchronously occurring factors, to one another to form thereal-time system; and testing if the connected sections operateconsistently.
 11. The method of claim 10, wherein the testing operationcomprises: reading a task start state of the rear section of thereal-time system and a task end state of the front section of thereal-time system; comparing the task start state of the rear sectionwith corresponding the task end state of the front section; anddetermining whether or not the task start state of the rear sectionagree with the task end state of the front section.
 12. The method ofclaim 11, wherein the task state includes Dormant, Wait, Ready and Run.13. A computer program product for designing a real-time systeminvolving a plurality of tasks, the computer program product comprising:testing whether or not task operations arranged in time series in eachsection of the real-time system are affected by asynchronously occurringfactors.
 14. The computer program product of claim 13, wherein thetesting operation comprises: extracting the asynchronously occurringfactor of each section of the real-time system; and testing whether ornot the asynchronously occurring factor occurs branching of the eachsection.
 15. The computer program product of claim 13, wherein theasynchronously occurring factor includes interrupt and time-out process.16. A computer program product for designing a real-time systeminvolving a plurality of tasks, the computer program product comprising:connecting sections each containing a series of tasks that are notaffected by asynchronously occurring factors, to one another to form thereal-time system; and testing if the connected sections operateconsistently.
 17. The program of claim 16, wherein the testing operationcomprises: reading a task start state of the rear section of thereal-time system and a task end state of the front section of thereal-time system; comparing the task start state of the rear sectionwith corresponding the task end state of the front section; anddetermining whether or not the task start state of the rear sectionagree with the task end state of the front section.
 18. The program ofclaim 17, wherein the task state includes Dormant, Wait, Ready and Run.